Designing an IT (Information Technology) system set up in computer network, such as an online transaction system, has been separately supported by different systems, one of which designs the throughput of the system and other of which designs the reliability of it.
On one hand, designing the throughput of a system has been commonly done by a discrete type simulation, in which various events are modeled from the viewpoint of a time that a serious change arises in changeable situations (see Japanese Patent Publication Laid-open No. 2002-63218).
FIG. 1 is a diagram explaining a discrete type simulation and illustrates a model of an objective system. This model represents an event where queues 101˜105 are generated against a plurality of processors (circles in FIG. 1). This is called the “multistage queuing model”. In this multistage queuing model, transactions arrived at the queues 101˜105 per unit time are represented by the numbers λ1˜λ5, respectively.
In addition, transactions dealt with by the processors corresponding to the queues 101˜105 per unit time are represented by the numbers (throughputs) μ1˜μ5, respectively. Here both the numbers λ1˜λ5 and μ1˜μ5 are supposed as parameters (variable factors) in the discrete type simulation.
Such a discrete type simulation is performed on the basis of a scenario specifying how each of the parameters must be changed. After performing the simulation, it is carried out to take measures to solve bottlenecks (throughput lacks etc.) discovered from a result of the simulation.
FIG. 2 is a flow chart showing procedures by a design supporting system for system throughput upon employing a conventional discrete type simulation technique. In this conventional design supporting system for system throughput, there is drafted a model on the ground of the following input data: constitutive instruments of the system; connections among the constitutive instruments; handling processes of the constitutive instruments; respective throughputs of the constitutive instruments; a probability that an output branches off at each node; a basic system idea; and a design standard value for system throughput (step S1). Then the discrete type simulation is performed to evaluate the system throughput (step S2).
Next, it is executed to judge whether the system throughput exceeds the design standard value or not (step S3). If the system throughput does not exceed the design standard value, then it is executed to extract a bottleneck part of the system from the simulation result and further consider an improvement idea (step S4). Thereafter, this routine returns to step S1 to draft a model of the improvement idea, and the operations at steps S1˜S3 are iterated until the system throughput reaches at the design standard value. At step S3, if the system throughput exceeds the design standard value, an improvement idea at that time is adopted as the system idea (S5).
On the other hand, designing the reliability of a system has been commonly done by a fault tree analysis. The fault tree analysis is used in the designing of a plant, such as a nuclear power plant, in order to ensure the safety of the plant. In detail, it is carried out to first assume a trouble event, secondly calculate probabilities causing the trouble event, and quantitatively analyze that the occurrence probability of the trouble event is reduced to almost zero. As well as being a major analytic technique exploited in a reliability engineering and its related fields, the fault tree analysis has been adopted in designing an IT system (see Japanese Patent Publication Laid-Open No. 2003-67043, and “Latest Designing and Investigating Technique (2nd. edition)”, Kenji KITAGAWA, Dec. 14, 1987, Techno-system Co. Ltd.
In the fault tree analysis, after selecting a top event to be assumed, it is carried out to explore primary factors causing the top event to introduce a logical relation among the primary factors. Here the logical relation is expressed in the form of a tree, logic symbols (AND, OR) are inscribed under the description of the top event, and the primary factors are inscribed under the description of the logic symbols. Then the similar steps are iterated from each primary factor to secondary factors, tertiary factor, . . . , in order to segmentalize the event up to a level whose probability distribution can be determined by an experiment or the like. It is shown that the top event is generated by Boolean algebra from combinations starting from the lowest events (basic events) in the tree structure. Then it becomes possible to drive the failure probability of the top event from the failure probabilities of the basic events.
FIG. 3 is a flow chart showing procedures by a design supporting system for system reliability employing a conventional fault tree analysis. In this conventional design supporting system for system reliability, it is designed on the ground of the following input data: constitutive instruments in the system; connections among the constitutive instruments; handling processes of the constitutive instruments; a failure rate of each constitutive instrument (or subsystem) and its failure mode; a mission of each constitutive instrument (or subsystem) and its failure mode; a mission time of each constitutive instrument (or subsystem) and its failure mode; common failure causes; a basic system idea; and a design standard value for the failure probability of the system.
First, it is executed to suppose the breakdown of the system or an undesirable event in operation or performance of an objective system as a “top event”, and suppose events that couldn't be decomposed any more as “basic events”. Then it is performed to graphically input or/and edit a fault free structure (step S11), which is constructed from hierarchical events from the top event to the basic events, and interconnections among the hierarchical events.
Next, it is executed to convert the fault-tree data drafted at step S11 into a logical expression by Boolean algebra (step S12). Then it is executed to substitute the respective failure probabilities of the basic events into the logical expression driven at step S12 to calculate the failure probability of the top event (step S13). Next, it is executed to judge whether the system failure probability exceeds the design standard value or not (step S14). If the system failure probability does not exceed the design standard value, then it is performed to analyze the importance of each basic event, that is, how much each basic event does influence the failure probability of the top event obtained at step S13. In addition, by changing the failure probabilities of the basic events, their contribution ratios to the failure probability of the top event are calculated to seek an improvement idea (step S15). Thereafter, this routine returns to step S11 to draft a new fault tree structure for the improvement idea. In this way, a series of operations at steps S11˜S14 are iterated until the system failure probability reaches at the design standard value. When the system failure probability exceeds the design standard value, an improvement idea at that time is adopted as the system idea (step S16).